WIP debian/changelog: start 4.14.0-1~exp2

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

tools/xenpmd: Fix gcc10 snprintf warning

Add a check for snprintf return code and ignore the entry if we get an
error. This should in fact never happen and is more a trick to make gcc
happy and prevent compilation errors.

This is solving the following gcc warning when compiling for arm32 host
platforms with optimization activated:
xenpmd.c:92:37: error: '%s' directive output may be truncated writing
between 4 and 2147483645 bytes into a region of size 271
[-Werror=format-truncation=]

This is also solving the following Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970802

Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Wei Liu <wl@xen.org>
(cherry picked from commit 0dfddb2116e3757f77a691a3fe335173088d69dc)

xen/arm64: force gcc 10+ to always inline generic atomics helpers

Recent versions of gcc (at least 10.x) will not inline generic atomics
helpers by default. Instead they will expect the software to either link
with libatomic.so or implement the helpers, which would result in

undefined reference to `__aarch64_ldadd4_acq_rel'

for us (not having any local implementation).

To keep the previous behavior, force gcc to always inline the generic
atomics helpers.

Long term we probably want to avoid relying on gcc atomics helpers as
this doesn't allow us to switch between LSE and LL/SC atomics.

Suggested-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
(cherry picked from commit 5d45ecabe3c0b2097df623ab7b471f8915cfdde6)

d/xen-utils-common.xen.init: disable oom killer for xenstored

In case of oom killer terminating some process, we'd rather not see
xenstored go. Xenstored has an in-memory database, and when starting the
process again, it would be empty, which is very inconvenient. Xenstored
should already score quite low and have a fairly low memory footprint,
but according to the user report, it happened.

Closes: #961511
Suggested-by: Samuel Thibault <sthibault@debian.org>
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Commit patch queue (exported by git-debrebase)

[git-debrebase make-patches: export and commit patches]

Declare fast forward / record previous work

[git-debrebase pseudomerge: quick]

tools: Partially revert "Cross-compilation fixes."

This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7.

Doesn't look like much of 16504669c5cbb8b195d20412aadc838da5c428f7
actually remains due to passage of time.

Of the 3, both Python and pygrub appear to mostly be building just fine
cross-compiling.  The OCAML portion is being troublesome, this is going
to cause bug reports elsewhere soon.  The OCAML portion though can
already be disabled by setting OCAML_TOOLS=n and shouldn't have this
extra form of disabling.

Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
Acked-by: Wei Liu <wl@xen.org>
(cherry picked from commit 69953e2856382274749b617125cc98ce38198463)

tools: don't build/ship xenmon

It can't run with Python 3, and I'm not going to fix it.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

libxl: fix -Werror=stringop-truncation in libxl__prepare_sockaddr_un

In file included from /usr/include/string.h:495,
                 from libxl_internal.h:38,
                 from libxl_utils.c:20:
In function 'strncpy',
    inlined from 'libxl__prepare_sockaddr_un' at libxl_utils.c:1262:5:
/usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit fff1b7f50e75ad9535c86f3fcf425b4945c50a1c)

libxl: workaround gcc 10.2 maybe-uninitialized warning

It seems xlu_pci_parse_bdf has a state machine that is too complex for
gcc to understand. The build fails with:

    libxlu_pci.c: In function 'xlu_pci_parse_bdf':
    libxlu_pci.c:32:18: error: 'func' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       32 |     pcidev->func = func;
          |     ~~~~~~~~~~~~~^~~~~~
    libxlu_pci.c:51:29: note: 'func' was declared here
       51 |     unsigned dom, bus, dev, func, vslot = 0;
          |                             ^~~~
    libxlu_pci.c:31:17: error: 'dev' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       31 |     pcidev->dev = dev;
          |     ~~~~~~~~~~~~^~~~~
    libxlu_pci.c:51:24: note: 'dev' was declared here
       51 |     unsigned dom, bus, dev, func, vslot = 0;
          |                        ^~~
    libxlu_pci.c:30:17: error: 'bus' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       30 |     pcidev->bus = bus;
          |     ~~~~~~~~~~~~^~~~~
    libxlu_pci.c:51:19: note: 'bus' was declared here
       51 |     unsigned dom, bus, dev, func, vslot = 0;
          |                   ^~~
    libxlu_pci.c:29:20: error: 'dom' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       29 |     pcidev->domain = domain;
          |     ~~~~~~~~~~~~~~~^~~~~~~~
    libxlu_pci.c:51:14: note: 'dom' was declared here
       51 |     unsigned dom, bus, dev, func, vslot = 0;
          |              ^~~
    cc1: all warnings being treated as errors

Workaround it by setting the initial value to invalid value (0xffffffff)
and then assert on each value being set. This way we mute the gcc
warning, while still detecting bugs in the parse code.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit d25cc3ec93ebda030349045d2c7fa14ffde07ed7)

tools/xl/bash-completion: also complete 'xen'

We have the `xen` alias for xl in Debian, since in the past it was a
command that could execute either xl or xm.

Now, it always does xl, so, complete the same stuff for it as we have
for xl.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
[git-debrebase split: mixed commit: upstream part]

pygrub: Specify -rpath LIBEXEC_LIB when building fsimage.so

If LIBEXEC_LIB is not on the default linker search path, the python
fsimage.so module fails to find libfsimage.so.

Add the relevant directory to the rpath explicitly.

(This situation occurs in the Debian package, where
--with-libexec-libdir is used to put each Xen version's libraries and
utilities in their own directory, to allow them to be coinstalled.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

pygrub: Set sys.path

We install libfsimage in a non-standard path for Reasons.
(See debian/rules.)

This patch was originally part of `tools-pygrub-prefix.diff'
(eg commit 51657319be54) and included changes to the Makefile to
change the installation arrangements (we do that part in the rules now
since that is a lot less prone to conflicts when we update) and to
shared library rpath (which is now done in a separate patch).

(Commit message rewritten by Ian Jackson.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
squash! pygrub: Set sys.path and rpath

hotplug-common: Do not adjust LD_LIBRARY_PATH

This is in the upstream script because on non-Debian systems, the
default install locations in /usr/local/lib might not be on the linker
path, and as a result the hotplug scripts would break.

A reason we might need it in Debian is our multiple version
coinstallation scheme.  However, the hotplug scripts all call the
utilities via the wrappers, and the binaries are configured to load
from the right place anyway.

This setting is an annoyance because it requires libdir, which is an
arch-specific path but comes from a file we want to put in
xen-utils-common, an arch:all package.

So drop this setting.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

sysconfig.xencommons.in: Strip and debianize

Strip all options that are for stuff we don't ship, which is 1)
xenstored as stubdom and 2) xenbackendd, which seems to be dead code
anyway. [1]

It seems useful to give the user the option to revert to xenstored
instead of the default oxenstored if they really want.

[1] https://lists.xen.org/archives/html/xen-devel/2015-07/msg04427.html

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

vif-common: disable handle_iptable

Also see Debian bug #894013. The current attempt at providing
anti-spoofing rules results in a situation that does not have any
effect. Also note that forwarding bridged traffic to iptables is not
enabled by default, and that for openvswitch users it does not make any
sense.

So, stop cluttering the live iptables ruleset.

This functionality seems to be introduced before 2004 and since then it
has never got some additional love.

It would be nice to have a proper discussion upstream about how Xen
could provide some anti mac/ip spoofing in the dom0. It does not seem to
be a trivial thing to do, since it requires having quite some knowledge
about what the domU is allowed to do or not (e.g. a domU can be a
router...).

Fix empty fields in first hypervisor log line

Instead of:

    (XEN) Xen version 4.11.1 (Debian )
    (@)
    (gcc (Debian 8.2.0-13) 8.2.0) debug=n
    Thu Jan  3 19:08:37 UTC 2019

I'd like to see:

    (XEN) Xen version 4.11.1 (Debian 4.11.1-1~)
    (pkg-xen-devel@lists.alioth.debian.org)
    (gcc (Debian 8.2.0-13) 8.2.0) debug=n
    Thu Jan  3 22:44:00 CET 2019

The substitution was broken since the great packaging refactoring,
because the directory in which the build is done changed.

Also, use the Maintainer address from debian/control instead of the most
recent changelog entry. If someone wants to use the address to ask a
question, they will end up at the team mailing list, which is better
than an individual person.

docs/man/xen-vbd-interface.7: Provide properly-formatted NAME section

This manpage was omitted from
   docs/man: Provide properly-formatted NAME sections
because I was previously building with markdown not installed.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

shim: Provide separate install-shim target

When building on a 32-bit userland, the user wants to build 32-bit
tools and a 64-bit hypervisor.  This involves setting XEN_TARGET_ARCH
to different values for the tools build and the hypervisor build.

So the user must invoke the tools build and the hypervisor build
separately.

However, although the shim is done by the tools/firmware Makefile, its
bitness needs to be the same as the hypervisor, not the same as the
tools.  When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is
wrong.

So the user must invoke the shim build separately.  This can be done
with
   make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64

However, tools/firmware/xen-dir has no `install' target.  The
installation of all `firmware' is done in tools/firmware/Makefile.  It
might be possible to fix this, but it is not trivial.  For example,
the definitions of INST_DIR and DEBG_DIR would need to be copied, as
would an appropriate $(INSTALL_DIR) call.

For now, provide an `install-shim' target in tools/firmware/Makefile.

This has to be called from `install' of course.  We can't make it
a dependency of `install' because it might be run before `all' has
completed.  We could make it depend on a `shim' target but such
a target is nearly impossible to write because everything is done by
the inflexible subdir-$@ machinery.

The overally result of this patch is that existing make invocations
work as before.  But additionally, the user can say
  make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64
to install the shim.  The user must have built it already.
Unlike the build rune, this install-rune is properly conditional
so it is OK to call on ARM.

What a mess.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

tools/firmware/Makfile: Respect caller's CONFIG_PV_SHIM

This makes it easier to disable the shim build.  (In Debian we need to
build the shim separately because it needs different compiler flags
and a different XEN_COMPILE_ARCH.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

.gitignore: Add configure output which we always delete and regenerate

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

autoconf: Provide libexec_libdir_suffix

This is going to be used to put libfsimage.so into a path containing
the multiarch triplet.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools-libfsimage-prefix.diff

\o/

Do not build the instruction emulator

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools/tests/x86_emulator: Pass -no-pie -fno-pic to gcc on x86_32

The current build fails with GCC6 on Debian sid i386 (unstable):

 /tmp/ccqjaueF.s: Assembler messages:
 /tmp/ccqjaueF.s:3713: Error: missing or invalid displacement expression `vmovd_to_reg_len@GOT'

This is due to the combination of GCC6, and Debian's decision to
enable some hardening flags by default (to try to make runtime
addresses less predictable):
  https://wiki.debian.org/Hardening/PIEByDefaultTransition

This is of no benefit for the x86 instruction emulator test, which is
a rebuild of the emulator code for testing purposes only.  So pass
options to disable this.

These options will be no-ops if they are the same as the compiler
default.

On amd64, the -fno-pic breaks the build in a different way.  So do
this only on i386.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Topic misc
Gbp-Pq: Name toolstestsx86_emulator-pass--no-pie--fno.patch

Remove static solaris support from pygrub

Patch-Name: tools-pygrub-remove-static-solaris-support

Gbp-Pq: Topic misc
Gbp-Pq: Name tools-pygrub-remove-static-solaris-support

Do not ship COPYING into /usr/include

This is not wanted in Debian.  COPYING ends up in
/usr/share/doc/xen-*copyright.

Patch-Name: tools-include-no-COPYING.diff

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

config-prefix.diff

Patch-Name: config-prefix.diff

Gbp-Pq: Topic prefix-abiname
Gbp-Pq: Name config-prefix.diff

version

Delete configure output

These autogenerated files are not useful in Debian; dh_autoreconf will
regenerate them.

If this patch does not apply when rebasing, you can simply delete the
files again.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Delete config.sub and config.guess

dh_autoreconf will provide these back.

If this patch does not apply when rebasing, you can simply delete the
files again.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/changelog: All the things for 4.14.0-1~exp1

We're going to first do an upload to experimental. Either the same thing
goes as 4.14.0-1 to unstable later, or maybe it'll be something else,
but at least we have the possibility when adding ~exp1 now.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/rules: Add --host to tools configure target

Without this, we'll be building tools for the build machine, not the host
machine.

Signed-off-by: Elliott Mitchell <ehem+debian@m5p.com>
Reviewed-by: Ian Jackson <iwj@xenproject.org>

debian/rules: Combine shared Make args

The original author of debian/rules seemed to have planned to make use
of $(make_args_common), but never got to sharing combined values.  Since
some values are shareable, make use of the shared args.

Signed-off-by: Elliott Mitchell <ehem+debian@m5p.com>
Reviewed-by: Ian Jackson <iwj@xenproject.org>

debian/control: Fix python dependency

Debian's Xen build actually has two distinct Python dependencies.  The
build process itself needs Python's build machine runtime available to
run portions of the build written in Python.  The build process also
needs the host machine libraries in order to link Xen's Python libraries.

Signed-off-by: Elliott Mitchell <ehem+debian@m5p.com>
Acked-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: Standards-Version: 4.5.0

I read the upgrading checklist for changes after 3.9.4 up to 4.5.0 and I
don't see shocking things that we really need to do.

So, bump it.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/xen-utils-common.xen.init: use /run instead of /var/run

/var/run has been a symlink to /run for ages, and since Stretch it's
guaranteed to be available. Adapt the paths in here to use /run
directly.

Debian Policy Manual v4.0.0, Released May, 2017 checklist says:

    9.1.1 The stable release of Debian supports /run, so packages may
    now assume that it exists and do not need any special dependency on
    a version of initscripts.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/xen-utils-V.lintian-overrides.vsn-in: s/fsimage/xenfsimage/

I missed these ones in "debian/: Follow fsimage -> xenfsimage renaming"

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/xen-utils-V.lintian-overrides.vsn-in: fix rpath override

Lintian complains:

    E: xen-utils-4.14: custom-library-search-path usr/lib/xen-4.14/lib/python/xenfsimage.cpython-38-x86_64-linux-gnu.so /usr/lib/xen-4.14/lib/x86_64-linux-gnu
    N:
    N:    The binary or shared library sets RPATH or RUNPATH. This overrides the
    N:    normal library search path, possibly interfering with local policy and
    N:    causing problems for multilib, among other issues.
    N:
    N:    The only time a binary or shared library in a Debian package should set
    N:    RPATH or RUNPATH is if it is linked to private shared libraries in the
    N:    same package. In that case, place those private shared libraries in
    N:    /usr/lib/<package>. Libraries used by binaries in other packages should
    N:    be placed in /lib or /usr/lib as appropriate, with a proper SONAME, in
    N:    which case RPATH/RUNPATH is unnecessary.
    N:
    N:    To fix this problem, look for link lines like:
    N:        gcc test.o -o test -Wl,--rpath,/usr/local/lib
    N:    or
    N:        gcc test.o -o test -R/usr/local/lib
    N:    and remove the -Wl,--rpath or -R argument. You can also use the chrpath
    N:    utility to remove the RPATH.
    N:
    N:    Refer to https://wiki.debian.org/RpathIssue for details.
    N:
    N:    Severity: error
    N:
    N:    Check: binaries

    W: xen-utils-4.14: mismatched-override custom-library-search-path usr/lib/xen-4.14/lib/python/xenfsimage.so /usr/lib/xen-4.14/lib/x86_64-linux-gnu
    N:
    N:    The named tag could have been silenced but the context specified with
    N:    the override did not match.
    N:
    N:    Lintian may now provide a different context for the tag, or something
    N:    could have changed in a new version of your package. Either way,
    N:    overrides work best when you require only little context.
    N:
    N:    You can use wildcards, such as &ast; or &quest; in the context to makes
    N:    a match more likely.
    N:
    N:    Please remove or adjust the override, whichever suits your purpose.
    N:
    N:    Severity: warning
    N:
    N:    Check: lintian

The target file has a new name, with cpython-blurb in it. Wildcard that
part.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: drop autotools-dev build dependency

Lintian complains:

    W: xen source: useless-autoreconf-build-depends autotools-dev
    N:
    N:    Since compatibility level 10, debhelper enables the autoreconf sequence
    N:    by default.
    N:
    N:    It is therefore not necessary to specify build-dependencies on
    N:    dh-autoreconf or autotools-dev and they can be removed.
    N:
    N:    Severity: warning
    N:
    N:    Check: debhelper

So, drop it.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: remove XS-Python-Version

Lintian complains:

    W: xen source: python-version-current-is-deprecated XS-Python-Version
    N:
    N:    The use of "current" in the Python-Version or Python3-Version field is
    N:    deprecated.
    N:
    N:    Refer to Debian Python Policy section 3.4 (Specifying Supported
    N:    Versions) for details.
    N:
    N:    Severity: warning
    N:
    N:    Check: languages/python

So, drop it.

We could replace it with X-Python3-Version, but that documentation
says...

    "The optional X-Python3-Version field specifies the versions of
    Python 3 supported. When not specified, it defaults to all currently
    supported Python 3 versions."

...and I think that's fine for the python code included here. Actually,
I'm not sure, but yolo.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/xen-hypervisor-V-F.lintian-overrides.vsn-in: fix override

First of all, debug-package-should-be-named-dbg does not exist any more,
but debug-suffix-not-dbg does, change it.

Lintian complains:

    W: xen-hypervisor-4.14-amd64: debug-suffix-not-dbg usr/lib/debug/xen-4.14.0.efi.map.gz
    N:
    N:    This package provides at least one file in /usr/lib/debug, which is
    N:    intended for detached debugging symbols, but the package name does not
    N:    end in "-dbg". Detached debugging symbols should be put into a separate
    N:    package, Priority: extra, with a package name ending in "-dbg".
    N:
    N:    Refer to Debian Developer's Reference section 6.7.9 (Best practices for
    N:    debug packages) for details.
    N:
    N:    Severity: warning
    N:
    N:    Check: files/debug

...and also complains:

    W: xen-hypervisor-4.14-amd64: mismatched-override debug-suffix-not-dbg usr/lib/debug/xen-*-pre.efi.map.gz
    N:
    N:    The named tag could have been silenced but the context specified with
    N:    the override did not match.
    N:
    N:    Lintian may now provide a different context for the tag, or something
    N:    could have changed in a new version of your package. Either way,
    N:    overrides work best when you require only little context.
    N:
    N:    You can use wildcards, such as &ast; or &quest; in the context to makes
    N:    a match more likely.
    N:
    N:    Please remove or adjust the override, whichever suits your purpose.
    N:
    N:    Severity: warning
    N:
    N:    Check: lintian

So, secondly, fix this by dropping the -pre part which prevents it from
matching.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: xen-doc: add ${misc:Depends}

Lintian complains:

    W: xen source: debhelper-but-no-misc-depends xen-doc
    N:
    N:    The source package uses debhelper, but it does not include
    N:    ${misc:Depends} in the given binary package's debian/control entry. Any
    N:    debhelper command may add dependencies to ${misc:Depends} that are
    N:    required for the work that it does, so recommended best practice is to
    N:    always add ${misc:Depends} to the dependencies of each binary package if
    N:    debhelper is in use.
    N:
    N:    Refer to the debhelper(7) manual page for details.
    N:
    N:    Severity: warning
    N:
    N:    Check: debhelper

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: fix xen-utils-4.14 python3 dependency

Lintian complains:

    E: xen-utils-4.14: python-script-but-no-python-dep usr/lib/xen-4.14/bin/convert-legacy-stream #!/usr/bin/python3
    N:
    N:    Packages with Python scripts should depend on the package python. Those
    N:    with scripts that specify a specific version of Python must depend,
    N:    recommend or suggest on that version of Python (exactly).
    N:
    N:    For example, if a script in the package uses #!/usr/bin/python, the
    N:    package needs a dependency on python. If a script uses
    N:    #!/usr/bin/python2.6, the package needs a dependency on python2.6. A
    N:    dependency on python (>= 2.6) is not correct, since later versions of
    N:    Python may not provide the /usr/bin/python2.6 binary.
    N:
    N:    If you are using debhelper, adding ${python3:Depends} or
    N:    ${python:Depends} to the Depends field and ensuring dh_python2 or
    N:    dh_python3 are run during the build should take care of adding the
    N:    correct dependency.
    N:
    N:    In some cases a weaker relationship, such as Suggests or Recommends,
    N:    will be more appropriate.
    N:
    N:    Severity: error
    N:
    N:    Check: scripts
    N:
    E: xen-utils-4.14: python-script-but-no-python-dep usr/lib/xen-4.14/bin/pygrub #!/usr/bin/python3
    E: xen-utils-4.14: python-script-but-no-python-dep usr/lib/xen-4.14/bin/verify-stream-v2 #!/usr/bin/python3
    E: xen-utils-4.14: python-script-but-no-python-dep usr/lib/xen-4.14/bin/xenpvnetboot #!/usr/bin/python3

The xen-utils-4.14 is indeed missing the python3 dependency. This is
probably because of the dh_python3 override that makes it skip dealing
with the ${python3:Depends} dependency:

    # dh_python3 does not know to look in the funny directory where
    # we put the versioned /usr/lib files including some python scripts.
    override_dh_python3:
    dh_python3
    dh_python3 -pxen-utils-$(upstream_version) \
    usr/lib/xen-$(upstream_version)/bin

So, just hardcode python3 as dependency, yolo.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

xen-utils-V.postinst.vsn-in: cosmetics

There were some tabs here, convert them to spaces like in the rest of
the file.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

xen-utils-V scripts: remove update-alternatives

This has been in here for ages. I guess that we can remove it now.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: s/libncurses5-dev/libncurses-dev/

libncurses5-dev is a transitional package for libncurses-dev

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/rules: Avoid using $(PWD) variable.

Fixes: lintian: debian-rules-should-not-use-pwd
See-also: https://lintian.debian.org/tags/debian-rules-should-not-use-pwd.html

debian/pycompat: remove obsolete file.

Fixes: lintian: debian-pycompat-is-obsolete
See-also: https://lintian.debian.org/tags/debian-pycompat-is-obsolete.html

debian/changelog: trim trailing whitespace.

Fixes: lintian: file-contains-trailing-whitespace
See-also: https://lintian.debian.org/tags/file-contains-trailing-whitespace.html

d/scripts/xen-init-list: python3 and remove cruft

This little script is used by the xendomains init script. See new
comment inside for more info.

* Change it to python3
* Remove all the obsolete xend related SXP cruft
* Remove all the overly obsessed object orientedness

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/scripts/xen-init-name: python3 and remove cruft

This little script is used by the xendomains init script. See new
comment inside for more info.

* Change it to python3
* Remove all the obsolete xend related SXP cruft
* Remove all the overly obsessed object orientedness

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/libxenstore3.0.symbols: drop xprintf

Exporting this was always a mistake.

The build will fail with:

  gcc xs_tdb_dump.o utils.o tdb.o talloc.o    -Wl,-z,relro -Wl,-z,now  -o xs_tdb_dump
  /usr/bin/ld: utils.o:./tools/xenstore/utils.h:27: multiple definition of
    `xprintf'; xs_tdb_dump.o:./tools/xenstore/utils.h:27: first defined here

Closes: #968965
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/control: add libxenhypfs[1]

This is a new library in upstream.  It has a stable ABI and a proper
soname, currently "1".

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/{rules,control}: switch to python 3

Debian Bullseye is going to release without python 2.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: add flex, bison

The build uses them apparently, now, and we didn't have it available, so
it would FTBFS.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: cleanup Uploaders

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

Update changelog for new upstream 4.14.0

[git-debrebase changelog: new upstream 4.14.0]

Update to upstream 4.14.0

[git-debrebase anchor: new upstream 4.14.0, merge]

README, Makefile: Xen 4.14.0 release

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Config.mk: Nail subtrees to the Xen 4.14.0 release tags

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

SUPPORT.md: Set version and release/support dates

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

d/xen-utils-common.xen.init: multi-version comment

Having the init script in a -common package (of which the version is
installed that matches the newest installed versioned other xen
packages) means that it also has to be able to deal with older Xen
versions.

Add a little reminder of this fact, because this can be a bit of a
surprise if you didn't realize yet.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/rules: Drop redundant sequence numbers in dh_installinit

Closes: #939560 (3/3)
Reported-by: Guillem Jover <guillem@debian.org>
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/rules: Improve comment about hardening options

Closes: #939560 (2/3)
Reported-by: Guillem Jover <guillem@debian.org>
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/rules: Set DEB_BUILD_MAINT_OPTIONS in shell

This makes these hardening options actually effective.

Closes: #939560 (1/3)
Reported-by: Guillem Jover <guillem@debian.org>
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/xen-utils-V.*: Use @version@ instead of hardcoded version

I guess this doesn't need a lot of extra explanation...

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/: Follow fsimage -> xenfsimage renaming

In the upstream code, the name of this library has been changed to make
it more Xen-specific. Also filesystem paths have changed. Update
accordingly.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/rules: remove pkgconfig stuff

These files are not present any more. Remove the obsolete lines that
would place them somewhere.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: adjust to 4.14

Update changelog for new upstream 4.14.0~rc6+2-g23fe1b8d51

[git-debrebase changelog: new upstream 4.14.0~rc6+2-g23fe1b8d51]

Update to upstream 4.14.0~rc6+2-g23fe1b8d51

[git-debrebase anchor: new upstream 4.14.0~rc6+2-g23fe1b8d51, merge]

Revert "SUPPORT.md: Set version and release/support dates"

This reverts commit e4670f8b045b11a524171b119d9d4a20bf643367.

SUPPORT.md: Set version and release/support dates

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Julien Grall <jgrall@amazon.com>

SUPPORT.md: Spell Experimental correctly

Signed-off-by: Julien Grall <jgrall@amazon.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
(cherry picked from commit 139ce42388c3fe7096a09b3d397250fe14906809)

docs: Replace non-UTF-8 character in hypfs-paths.pandoc

From the docs cronjob on xenbits:

  /usr/bin/pandoc --number-sections --toc --standalone misc/hypfs-paths.pandoc --output html/misc/hypfs-paths.html
  pandoc: Cannot decode byte '\x92': Data.Text.Internal.Encoding.decodeUtf8: Invalid UTF-8 stream
  make: *** [Makefile:236: html/misc/hypfs-paths.html] Error 1

Fixes: 5a4a411bde4 ("docs: specify stability of hypfs path documentation")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
(cherry picked from commit 9ffdda96d9e7c3d9c7a5bbe2df6ab30f63927542)

docs: specify stability of hypfs path documentation

In docs/misc/hypfs-paths.pandoc the supported paths in the hypervisor
file system are specified. Make it more clear that path availability
might change, e.g. due to scope widening or narrowing (e.g. being
limited to a specific architecture).

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Paul Durrant <paul@xen.org>
master commit: 5a4a411bde4f73ff8ce43d6e52b77302973e8f68
master date: 2020-07-20 13:38:00 +0200

x86: restore pv_rtc_handler() invocation

This was lost when making the logic accessible to PVH Dom0.

While doing so make the access to the global function pointer safe
against races (as noticed by Roger): The only current user wants to be
invoked just once (but can tolerate to be invoked multiple times),
zapping the pointer at that point.

Fixes: 835d8d69d96a ("x86/rtc: provide mediated access to RTC for PVH dom0")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
master commit: f8fe3c07363d11fc81d8e7382dbcaa357c861569
master date: 2020-07-15 15:46:30 +0200

Branch 4.14: Turn off debug on this stable branch

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

SUPPORT.md: Set release notes link

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

pvcalls: Document correctly and explicitely the padding for all arches

The specification of pvcalls suggests there is padding for 32-bit x86 at
the end of most the structure. However, they are not described in in the
public header.

Because of that all the structures would have a different size between
32-bit x86 and 64-bit x86.

For all the other architectures supported (Arm and 64-bit x86), the
structure have the sames sizes because they contain implicit padding
thanks to the 64-bit alignment of the field uint64_t field.

Given the specification is authoritative, the padding will now be the
same for all architectures. The potential breakage of compatibility is
ought to be fine as pvcalls is still a tech preview.

Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Paul Durrant <paul@xen.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>

pvcalls: Clearly spell out that the header is just a reference

A recent thread on xen-devel [1] pointed out that the header was
provided as a reference for the specification.

Unfortunately, this was never written down in xen.git so for an external
user (or a reviewer) it is not clear whether the spec or the header
should be followed when there is a conflict.

To avoid more confusion, a paragraph is added at the top of the header
to clearly spell out it is only provided for reference.

[1] https://lore.kernel.org/xen-devel/alpine.DEB.2.21.2006151343430.9074@sstabellini-ThinkPad-T480s/

Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Paul Durrant <paul@xen.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>

Commit patch queue (exported by git-debrebase)

[git-debrebase make-patches: export and commit patches]

Declare fast forward / record previous work

[git-debrebase pseudomerge: quick]

debian/changelog: finish 4.11.4+24-gddaaccbbab-1

tools/xl/bash-completion: also complete 'xen'

We have the `xen` alias for xl in Debian, since in the past it was a
command that could execute either xl or xm.

Now, it always does xl, so, complete the same stuff for it as we have
for xl.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
[git-debrebase split: mixed commit: upstream part]

pygrub: Specify -rpath LIBEXEC_LIB when building fsimage.so

If LIBEXEC_LIB is not on the default linker search path, the python
fsimage.so module fails to find libfsimage.so.

Add the relevant directory to the rpath explicitly.

(This situation occurs in the Debian package, where
--with-libexec-libdir is used to put each Xen version's libraries and
utilities in their own directory, to allow them to be coinstalled.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

pygrub: Set sys.path

We install libfsimage in a non-standard path for Reasons.
(See debian/rules.)

This patch was originally part of `tools-pygrub-prefix.diff'
(eg commit 51657319be54) and included changes to the Makefile to
change the installation arrangements (we do that part in the rules now
since that is a lot less prone to conflicts when we update) and to
shared library rpath (which is now done in a separate patch).

(Commit message rewritten by Ian Jackson.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
squash! pygrub: Set sys.path and rpath

hotplug-common: Do not adjust LD_LIBRARY_PATH

This is in the upstream script because on non-Debian systems, the
default install locations in /usr/local/lib might not be on the linker
path, and as a result the hotplug scripts would break.

A reason we might need it in Debian is our multiple version
coinstallation scheme.  However, the hotplug scripts all call the
utilities via the wrappers, and the binaries are configured to load
from the right place anyway.

This setting is an annoyance because it requires libdir, which is an
arch-specific path but comes from a file we want to put in
xen-utils-common, an arch:all package.

So drop this setting.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

sysconfig.xencommons.in: Strip and debianize

Strip all options that are for stuff we don't ship, which is 1)
xenstored as stubdom and 2) xenbackendd, which seems to be dead code
anyway. [1]

It seems useful to give the user the option to revert to xenstored
instead of the default oxenstored if they really want.

[1] https://lists.xen.org/archives/html/xen-devel/2015-07/msg04427.html

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

vif-common: disable handle_iptable

Also see Debian bug #894013. The current attempt at providing
anti-spoofing rules results in a situation that does not have any
effect. Also note that forwarding bridged traffic to iptables is not
enabled by default, and that for openvswitch users it does not make any
sense.

So, stop cluttering the live iptables ruleset.

This functionality seems to be introduced before 2004 and since then it
has never got some additional love.

It would be nice to have a proper discussion upstream about how Xen
could provide some anti mac/ip spoofing in the dom0. It does not seem to
be a trivial thing to do, since it requires having quite some knowledge
about what the domU is allowed to do or not (e.g. a domU can be a
router...).

Fix empty fields in first hypervisor log line

Instead of:

    (XEN) Xen version 4.11.1 (Debian )
    (@)
    (gcc (Debian 8.2.0-13) 8.2.0) debug=n
    Thu Jan  3 19:08:37 UTC 2019

I'd like to see:

    (XEN) Xen version 4.11.1 (Debian 4.11.1-1~)
    (pkg-xen-devel@lists.alioth.debian.org)
    (gcc (Debian 8.2.0-13) 8.2.0) debug=n
    Thu Jan  3 22:44:00 CET 2019

The substitution was broken since the great packaging refactoring,
because the directory in which the build is done changed.

Also, use the Maintainer address from debian/control instead of the most
recent changelog entry. If someone wants to use the address to ask a
question, they will end up at the team mailing list, which is better
than an individual person.

Revert "tools-xenstore-compatibility.diff"

Following recent discussion in pkg-xen-devel and xen-devel,
  https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg00838.html
I am dropping this patch.

For now I revert it.  When we next debrebase, we can (if we like)
throw away both the original patch, and this revert.

This reverts commit 5047884c76849b67e364bc525d1b3b55e781cf16.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

docs/man/xen-vbd-interface.7: Provide properly-formatted NAME section

This manpage was omitted from
   docs/man: Provide properly-formatted NAME sections
because I was previously building with markdown not installed.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools/firmware/Makefile: CONFIG_PV_SHIM: enable only on x86_64

Previously this was *dis*abled for x86_*32*.  But if someone should
run some of this Makefile on ARM, say, it ought not to be built
either.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

shim: Provide separate install-shim target

When building on a 32-bit userland, the user wants to build 32-bit
tools and a 64-bit hypervisor.  This involves setting XEN_TARGET_ARCH
to different values for the tools build and the hypervisor build.

So the user must invoke the tools build and the hypervisor build
separately.

However, although the shim is done by the tools/firmware Makefile, its
bitness needs to be the same as the hypervisor, not the same as the
tools.  When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is
wrong.

So the user must invoke the shim build separately.  This can be done
with
   make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64

However, tools/firmware/xen-dir has no `install' target.  The
installation of all `firmware' is done in tools/firmware/Makefile.  It
might be possible to fix this, but it is not trivial.  For example,
the definitions of INST_DIR and DEBG_DIR would need to be copied, as
would an appropriate $(INSTALL_DIR) call.

For now, provide an `install-shim' target in tools/firmware/Makefile.

This has to be called from `install' of course.  We can't make it
a dependency of `install' because it might be run before `all' has
completed.  We could make it depend on a `shim' target but such
a target is nearly impossible to write because everything is done by
the inflexible subdir-$@ machinery.

The overally result of this patch is that existing make invocations
work as before.  But additionally, the user can say
  make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64
to install the shim.  The user must have built it already.
Unlike the build rune, this install-rune is properly conditional
so it is OK to call on ARM.

What a mess.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

tools/firmware/Makfile: Respect caller's CONFIG_PV_SHIM

This makes it easier to disable the shim build.  (In Debian we need to
build the shim separately because it needs different compiler flags
and a different XEN_COMPILE_ARCH.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

.gitignore: Add configure output which we always delete and regenerate

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

autoconf: Provide libexec_libdir_suffix

This is going to be used to put libfsimage.so into a path containing
the multiarch triplet.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools-libfsimage-prefix.diff

Patch-Name: tools-libfsimage-prefix.diff

Gbp-Pq: Topic prefix-abiname
Gbp-Pq: Name tools-libfsimage-prefix.diff